Last update: 2020-11-07

This sample scenario has been provided by individual contributors and is not updated frequently.

This guide documents the procedure for protecting Remote Desktop Services (RDS) through native enforcement in the Remote Desktop Gateway (RDGW), extending Network Policy Server (NPS) RADIUS to SafeNet Trusted Access (STA) and authenticating the requesting user with push authentication to SafeNet MobilePASS+.

This guide also documents an alternative architecture where instead of RADIUS, a SafeNet agent is deployed and co-located with NPS to facilitate agent-based authentication with STA over an encrypted tunnel (TLS 1.2 over 443). Related to this, a proposed High Availability (HA) architecture is also documented.

The guide also briefly expands on troubleshooting tools and procedures related to deployment.

This guide documents alternative deployment architectures. These do not replace official SafeNet deployment architectures using RDWeb and RDGW agents (see the Support Portal for agent downloads and documentation).

Prerequisites

The following prerequisites must be met:

• RDGW is configured and published with valid public certificates.

• RDGW Resource Authorization Policy (RD RAP) is configured to allow access to required resources.

• NPS role is installed for RDGW Connection Authorization Policy (RD CAP).

• An auth node for the RDGW server is configured in STA.

• A user with the SafeNet MobilePASS+ authenticator is enrolled.

Solution architecture

The following diagram shows the high-level target architecture. The user requests a remote desktop service and enters their username and domain password. The access request is intercepted by the RDGW policy and forwarded to STA over RADIUS (UDP 1812) via Microsoft NPS. STA then sends an OTP push notification to the requesting user’s mobile device. The user approves the push request and is authorized to the remote desktop service.

See deployment options, for information about using an on-premise NPS server with SafeNet Agent for NPS installed.

Step 1: Configure RD CAP policy

Configure RD CAP to create all the required policies in the local NPS server, and to allow forwarding the RADIUS requests to the STA Cloud RADIUS.

1. Open Server Manager and click Remote Desktop Services.

2. In the Remote Desktop Services, click Servers.

3. Right-click your server and select RD Gateway Manager.

   

4. In the RD Gateway Manager, right-click the server name and expand Policies.

5. Click Central Network Policy Servers.

6. On the right side, click Configure Central RD CAP, and when the server properties open, click RD CAP Store.

   

7. Select Central server running NPS. In the Enter a name or IP address for the server running NPS field, type the RADIUS server FQDN or IP address and click Add. Depending on your service zone select the appropriate FQDN or IP address:

   Service zone	FQDN	IP address
   EU	radius1.eu.safenetid.com radius2.eu.safenetid.com	52.47.114.37 52.47.42.111
   US	radius1.us.safenetid.com radius2.us.safenetid.com	52.39.199.98 54.191.224.26
   Classic	rad1.safenet-inc.com rad2.safenet-inc.com	109.73.120.148 69.20.230.201

   1. In the Enter a new shared secret field, type your shared secret and click OK.

      Use the same shared secret in Step 3: Configure an auth node for RDGW

      

   2. Click Apply and OK to save the RD CAP settings.

   Step 2: Adjust NPS policies and settings

   The RD CAP configuration policy creates the necessary policies and settings in NPS. You must adjust those policies and settings to allow push authentication to work correctly.

   1. Open NPS and expand RADIUS Clients and Servers.

   2. Click Remote RADIUS Server.

   3. Double-click the policy named TS GATEWAY SERVER GROUP, which was created by RD CAP.

   4. Select the RADIUS server (created by RD CAP) and click Edit.

   5. In the Edit RADIUS Server window, click Load Balancing.

   6. To allow enough time for push authentication to complete, set the value of the following fields to 60:

      • Number of seconds without response before request is considered dropped

      • Number of seconds between requests when the server is identified as unavailable

      

   7. Click OK to save the timeout settings, and Apply and OK to save the RADIUS server settings.

   8. Expand Policies and click Connection Request Policies.

   9. Double-click the policy named TS GATEWAY AUTHORIZATION POLICY, which was created by RD CAP.

   10. Click Conditions and adjust the conditions based on the company needs (for example Group Membership or Date and Time restrictions).

   11. Click Settings, and then click Authentication. Verify that the Forward requests to the following remote RADIUS server group for authentication option is selected and is set to TS GATEWAY SERVER GROUP.

       

       By default, RDG sends the username in DOMAIN\User format. If the STA user doesn’t have a username or an alias in the same format, the authentication fails. To overcome this, UPN stripping is required. Follow the steps below to configure attribute manipulation rule to adjust the username.

   12. Click Attribute and change the attribute to be adjusted to User-Name.

   13. Click Add to add a new Attribute Manipulation Rule.

   14. Enter the following under Rules:

       Find: (.*)\\(.*)

       Replace With: $2

   15. Click OK to save the attribute settings, and Apply and OK to save the connection policy.

       

   16. Click Network Policies.

   17. Review and adjust the policy as required and then close NPS.

   The RDG server side configurations are complete.

   Step 3: Configure an auth node for RDGW

   To be able to use RDGW with STA RADIUS, create an auth node with the public IP of the RDG server.

   1. Open the STA Token Management console.

   2. Navigate to the Comms tab.

   3. Scroll down to Auth Nodes and click Auth Nodes.

   4. Click Add to add a new auth node:

      

   5. In Auth Node Name, type any name, such as RD Gateway.

   6. In Low IP Address in Range, type the public IP address of your RDG server.

   7. Select Configure FreeRADIUS Synchronization.

   8. In Shared Secret, enter the same shared secret that you created in the RD CAP configuration in Step 1: Configure RD CAP policy.

   9. Click Save to save the newly created auth node.

   Step 4: Test the configuration

   To test the configuration, adjust the RDP connection to use RD Gateway. The connection flow first establishes a connection to the RDG, which prompts the user to authenticate using their domain username and password (if the credentials haven’t been saved yet). It also sends a push authentication to the user’s SafeNet MobilePASS+ token. After successful push authentication, the user is connected to the remote desktop.

   Depending on the RDP configuration, the user might be prompted for the credentials for the remote desktop, or SSO can be used so that the credentials provided during the connection to RDG are also used for the remote desktop. These options are configured in Remote Desktop Services – Deployment Properties.

   

   1. Open RDP (mstsc) and click Advanced.

   2. Under Connect from Anywhere click Settings.

   3. Click Use these RD Gateway server settings.

   4. In Server Name, type the FQDN of your RDG server.

   5. Modify the Log-on method and Bypass RD Gateway server for local addresses as required.

      

   6. Click OK to save the settings.

   7. Click Connect to initiate the RDP connection through RD Gateway.

      The user is asked to provide the domain credentials, if the credentials haven’t already been saved.

      

      After providing the credentials, the connection initiates:

      

      The user receives and approves the push authentication request:

      

      After approving the push authentication request, the connection is established.

      

   Deployment options

   The deployment demonstrated in this guide is based on RADIUS communication between Microsoft Network Policy Server (NPS) and STA, using a single NPS instance.

   However, it is also possible to deploy this solution using an additional NPS instance together with the SafeNet Agent for NPS. In this deployment model, the RDGW NPS communicates locally to an additional NPS using RADIUS and acting as a client. SafeNet Agent for NPS then communicates to STA using HTTPS (port 443).

   The approach may be favorable when the first NPS instance is not allowed internet access or when RADIUS over the internet is not desired.

   A high-level architecture of this alternative deployment model is shown below:

   

   Service zone	FQDN	Port
   EU	cloud.eu.safenetid.com	443
   US	cloud.us.safenetid.com	443
   Classic	agent1.safenet-inc.com	443

   High availability

   Expanding on the deployment architecture, the diagram below shows a high-level architecture aimed at achieving redundancy or high availability in the solution. Here, components are mirrored to a second datacenter or zone, and configured to communicate to two RDG, NPS, and so on. If one service is not available, another service is requested.

   High availability in STA is ensured by the service provider (Thales Group) as long as the customer configures FQDNs instead of IP addresses in directing traffic at the STA virtual server.

   

   Troubleshooting

   Test and troubleshooting tools

   If possible, download the following tools to the servers in in your RDGW and STA architecture:

   NTRadPing

   You can download NTRadPing here.

   Wireshark

   You can download Wireshark here.

   Command reference

   The following commands are used from command line (CMD) to more rapidly recycle the NPS service:

   Command	Description
   net stop ias	Stops the NPS service
   net start ias	Starts the NPS service

   Common issues

   Missing or wrongly defined auth node

   Whether you configure NPS to communicate directly to STA over RADIUS (UDP 1812) or you employ the SafeNet Agent for NPS to communicate to STA over TLS (443), you must define an auth node in the virtual server corresponding to the external IP address of your server. Verify that IP address using an online tool such as https://www.whatsmyip.org/.

   Proxy impedes communication

   Open a command line window and issue the following command to learn if a proxy is present:

   netsh winhttp show proxy

   Set requests to inherit any proxy configuration from Internet Explorer settings:

   netsh winhttp import proxy source = ie

   Firewall impedes communication

   Install Wireshark and run a capture when attempting a connection. To simplify, run the test using NTRadPing first and if it is successful, then move on to include actual components. A successful connection appears as highlighted below.

   

   An unsuccessful connection will likely fail after resolving the STA FQDNs to IP addresses (follow the TCP stream and it will show reconnection attempts).